feat(coverage-recipe): add front end coverage for jest #401
Conversation
lib/potassium/recipes/coverage.rb
Outdated
| @@ -32,4 +44,18 @@ def configure_rails_helper | |||
| end | |||
| end | |||
| end | |||
|
|
|||
| def add_coverage_config(js_package) | |||
| js_package['scripts']['test'] = 'jest --changedSince=master' | |||
There was a problem hiding this comment.
Acá con esto del --changedSince=master me entra la duda. Esto haría que siempre que se corra yarn test, solo se testeen los archivos con cambios con respecto a master. Pero por lo que entiendo, ese comando debería siempre correr todos los tests. Lo que se tiene que limitar a que sea solo con respecto a los cambios de master es lo que revise el linter (lo que iría en la otra tarjeta). Osea creo que esto debería mantenerse con el valor anterior, test: "jest" y cuando se vea lo de CI/linter habría que ver una manera de que al correr eso se genere un reporte que considere solo los cambios de master.
No estoy seguro si, así que invoco a @ldlsegovia pa que me corrija
There was a problem hiding this comment.
Hola, vengo de 🐸. Hay un par de proyectos que usan main en vez de master, habría que manejar ese caso también 🤔
There was a problem hiding this comment.
- Si el reporte es un html que uno entra a ver, deberían incluirse todos los archivos.
- Si el reporte es el que se muestra en la terminal, luego del correr los tests, mejor que sea con el diff con master para que uno sepa a qué no le agregó tests
- En CI, también con el diff para que el mono no mate a comentarios.
There was a problem hiding this comment.
@ldlsegovia claro, pero el yarn test debería correr todos los tests, solo que cambia el scope dependiendo del reporte que se genere, eso?
There was a problem hiding this comment.
@gmq mmm se podrá considerar ese caso? quizás hay que cambiar esa configuración manualmente si se decide ir por main 🤔 en otros lados tambn se asume que es master si, o acá al menos
There was a problem hiding this comment.
Toda la razón, ignórenme :shame:
There was a problem hiding this comment.
está el problema de que no es tan customizable de qué tests hacer coverage, se hacen automáticos de los que se corren nomás, entonces quizás una solución sería tener dos comandos, seguir con el yarn test como está y agregar uno que solo vea tus cambios y genere el coverage, y sea ese último el que el mono revise para molestarte
There was a problem hiding this comment.
suena bien eso, démosle con tener los dos comandos separados. Después cuando se haga lo de CI se pueden correr dos veces los tests ahí, una para los tests corriéndolos todos, y otra corriendo solo con los cambios desde master para el linting.
Y duda: como funciona el reporter usando yarn test:watch? Te va mostrando un reporte del archivo que se va corriendo?
There was a problem hiding this comment.
sí, con yarn test:watch te muestra el coverage de los archivos que se van corriendo, funciona igual que un --onlyChanged
FloValdes
force-pushed
the
coverage-front
branch
from
435cc9d to
01c339b
Compare
Context
Potassium uses Jest for testing frontend code when using Vue. Jest provides some options to report test coverage.
Changes
Change the
coveragerecipe to add the necessary setup for Jest test coverage (if Jest is used). It modifies the existingpackage.jsonto add the coverage configuration.